Software testing methods fall into two general categories: white box testing and black box testing. White box testing methods entail exposing and statically analyzing the internal workings of a software application, without executing the application. Black box testing methods, on the other hand, entail testing an application during its execution and without relying on any knowledge of the internal structure of the application. Although white box testing provides the advantage of revealing the precise nature and location of a potential vulnerability of an application, as the application has not been executed, any such exposed vulnerability is theoretical, providing no proof of vulnerability to the developer. Additionally, the exposed vulnerability is seen from a perspective internal to the application, whereas it may be advantageous to view the vulnerability from a user's perspective.
Conversely, having executed the application, black box testing both provides the developer with proof of vulnerability, and exposes susceptibilities to attacks from a user's point of view. However, black box testing is often computationally expensive as the tester is ‘blind’ to the internal structure of the application, requiring many execution attempts before a vulnerability is discovered. Typically, each input parameter may have numerous possible test values. As the number of input parameters increases, the number of possible permutations of input scenarios become huge. Systems and methods for reducing the number of input scenarios for black box testing would thus be advantageous.